Fix IRQL_NOT_LESS_OR_EQUAL BSOD in Windows 11
Run verifier /standard /all in an elevated Command Prompt, restart, and use your PC normally until it crashes again. That one command does more to solve IRQL_NOT_LESS_OR_EQUAL than any registry tweak, driver "fix" tool, or clean install you'll find elsewhere — because this stop code is almost always a driver problem, and Driver Verifier is the tool Microsoft built specifically to catch drivers misbehaving in exactly the way that causes this crash. Everything below explains why that command works, how to read what it produces, and what to do once you actually know which driver is at fault. Don't reinstall Windows before you try this.
What does IRQL_NOT_LESS_OR_EQUAL actually mean?
The bug check value is 0xA. Microsoft's driver documentation describes it plainly: Windows or a kernel-mode driver tried to access memory at an address it wasn't allowed to touch while running at an interrupt request level (IRQL) that was too high for that kind of access. In practice, that almost always means a driver used a bad pointer — something already freed, something that was never valid, or memory that's pageable being accessed at a moment when paging isn't allowed. It's a driver-authoring bug, not something you caused by clicking the wrong thing, and the fix is finding which driver, then updating, rolling back, or removing it.
Is this the same thing as DRIVER_IRQL_NOT_LESS_OR_EQUAL?
Related, but not identical. That's bug check 0xD1, and Microsoft documents it as a narrower case of the same underlying problem — specifically a driver accessing pageable or invalid memory while running at DISPATCH_LEVEL or higher. If your blue screen names 0xD1 rather than 0xA, the diagnostic approach below still applies almost unchanged; you're chasing the same category of driver misbehavior, just under a slightly different technical definition.
Do I need to read a memory dump to fix this?
You don't strictly need to, but skipping it means guessing, and guessing wastes more time than the twenty minutes it takes to read one properly. Install WinDbg Preview from the Microsoft Store, then open your most recent crash dump — Windows saves these as .dmp files under C:\Windows\Minidump by default, assuming crash dump creation hasn't been disabled. Inside WinDbg, run:
!analyze -vLook for two lines specifically: FAILURE_BUCKET_ID and MODULE_NAME. Together these usually name the actual driver file involved — something like nvlddmkm.sys (NVIDIA's display driver), dxgmms2.sys (part of the DirectX graphics memory manager, which is Microsoft's but often gets implicated because of how a third-party GPU driver is calling into it), or a network, audio, or storage vendor's .sys file. That name tells you where to focus everything downstream — driver rollback, driver update, or vendor tool uninstall.
What if the name I see looks like a core Windows file, not a third-party one?
This trips people up constantly. Seeing ntoskrnl.exe, Wdf01000.sys, or dxgmms2.sys in the crash doesn't mean Windows itself is broken. Those are shared framework and kernel files that legitimate third-party drivers call into constantly, and a bug in the calling driver often shows up as a fault inside the framework it's using — the framework is just where the invalid access actually happened, not necessarily where the mistake originated. Treat a Microsoft-owned file at the top of the stack as a strong hint to look one layer down, at whatever driver was active immediately before the crash, rather than as proof the problem is unfixable or that Windows is corrupted.
How do I actually run Driver Verifier without breaking my PC?
Driver Verifier stresses kernel-mode drivers deliberately, looking for exactly the kind of memory violations that cause this bug check, and it will force a crash faster and with much clearer attribution than waiting for the next spontaneous one. The one mistake that turns this from a diagnostic tool into a genuine problem is selecting every driver on the system at once — Microsoft's own guidance and every experienced Windows troubleshooter agree on this point. Do it narrower:
- Open an elevated Command Prompt and run
verifierto launch the GUI, or useverifier /standard /alldirectly if you want the standard test set applied broadly as a first pass. - If using the GUI, choose "Create custom settings," select the standard checks, then on the driver selection screen pick "Select driver names from a list" rather than "Automatically select all drivers" — narrow this to non-Microsoft drivers if you already have a suspect from WinDbg, or to all third-party drivers if you don't yet.
- Restart and use the PC normally, specifically repeating whatever activity tended to trigger the original crash — gaming, waking from sleep, heavy USB or network use.
- When it crashes again, the new stop code will very often be
DRIVER_VERIFIER_DETECTED_VIOLATION(0xC4) instead of 0xA, with the offending driver named directly and unambiguously in the bug check parameters.
If the machine won't boot normally with Verifier enabled — this does happen if the flagged driver is something Windows depends on early in boot — restart into Safe Mode and disable it from an elevated Command Prompt with verifier /reset, then try a narrower driver selection next time.
Don't leave Driver Verifier running long-term once you've identified the culprit. It adds real overhead and exists purely as a diagnostic mode — turn it off with verifier /reset once you've got your answer and applied the actual fix.
Symptom, confirming check, fix
| What you're seeing | Confirming check | Fix |
|---|---|---|
Crash names a specific third-party .sys file directly | !analyze -v in WinDbg shows it under MODULE_NAME | Update that driver from the vendor's site directly, or roll back if it just updated |
| Crash always happens during gaming or GPU-heavy tasks | Named module is a display driver (nvlddmkm.sys, amdkmdag.sys, or similar) or dxgmms2.sys | Clean GPU driver reinstall with DDU in Safe Mode, then install the current driver fresh |
| Crash happens on sleep/wake or with specific USB devices connected | Reproducible specifically tied to that action or device | Update or remove that device's driver; test with the device unplugged |
| No clear driver name, or it points at a Microsoft framework file only | Driver Verifier with a broad third-party selection converts the crash to 0xC4 with a named driver | Apply the fix for whatever Verifier names |
| Crash reproduces regardless of driver changes, load-independent | Memory Diagnostic (mdsched.exe) or MemTest86 shows errors | Faulty RAM — reseat, test sticks individually, replace as needed |
Does overclocking cause this?
Yes, often enough that it's worth checking before you spend an evening in WinDbg. An unstable CPU, RAM, or GPU overclock can produce IRQL_NOT_LESS_OR_EQUAL crashes that look identical to a genuine driver bug, because the underlying mechanism is similar — memory access failing in a way the system can't recover from cleanly. If you're running anything outside stock clocks and timings, including RAM running at an XMP or EXPO profile faster than the motherboard fully validates, revert everything to stock first and see if the crashes stop before you invest time chasing a driver. This is a five-minute BIOS visit versus potentially hours of dump analysis for a problem that was never software to begin with.
Should I check the System log in Event Viewer too?
It's worth a quick look alongside WinDbg, not instead of it. Open Event Viewer, go to Windows Logs > System, and filter for Critical and Error severity around the timestamp of your last crash. What you're looking for is corroboration — a warning about the same driver WinDbg named, a disk or storage controller error in the same few seconds, or a Kernel-Power Event ID 41 confirming the system genuinely didn't shut down cleanly rather than recovering gracefully. None of this replaces reading the actual dump, but it's a fast sanity check that either strengthens your WinDbg finding or occasionally reveals a second, unrelated issue happening at the same time that's worth separating out.
What about a BIOS or firmware update?
Worth checking, particularly on newer hardware or after a motherboard vendor releases a chipset or memory-controller fix. An outdated BIOS on a relatively new platform is a real, if less common, contributor to IRQL crashes, especially ones tied to memory training or PCIe device initialization at boot. Check your motherboard or laptop manufacturer's support page for your exact model and compare your current BIOS version against the latest available; if there's a specific changelog entry mentioning memory stability, PCIe, or Secure Boot, that's a stronger signal to update than a vague "general improvements" note. Back up anything important before flashing BIOS, and follow the manufacturer's exact procedure rather than a generic guide, since the process genuinely differs between vendors.
What if it's clearly the graphics driver?
This is common enough to spell out on its own. If WinDbg or Driver Verifier points at your GPU vendor's driver, don't just run the vendor's updater over the existing install — do a clean removal first. Boot into Safe Mode, run Display Driver Uninstaller (DDU), let it fully remove the existing driver and its leftover files, restart, then install the current driver directly from the vendor's site rather than through Windows Update or a bundled utility. A driver update installed on top of a partially corrupted existing one is a common reason "updating the driver" doesn't actually fix this crash — the old broken files are still partly there underneath.
What I would not do
- Run "driver updater" utilities that scan your whole system and update everything at once. These frequently install driver versions that aren't actually matched to your exact hardware revision, and if something breaks you won't know which of the dozen changes did it.
- Enable Driver Verifier with every driver selected at once on a machine you can't easily get into Safe Mode on. If the crash it forces happens to hit a driver Windows needs to boot, you can end up in a genuine boot loop. Start narrow.
- Assume it's RAM without testing. IRQL crashes get blamed on bad memory constantly in forum threads, and it's occasionally true, but a driver is the more common cause by a wide margin in the reports and documentation I've reviewed. Test memory, don't just assume it.
- Ignore the crash because "it only happens once a month." Infrequent doesn't mean harmless — it usually means the triggering condition is rare, not that the underlying bad pointer went away. It'll come back, often at a worse moment.
People sometimes ask whether reinstalling Windows entirely is ever necessary for this error — short answer: rarely, and only after you've confirmed through WinDbg or Driver Verifier that the fault genuinely isn't tied to a specific third-party driver you can update or remove. Because this bug check is so consistently driver-caused, jumping to a clean install first usually means reinstalling a dozen drivers you didn't need to touch, then reinstalling the exact same buggy one that caused the problem in the first place. If you want the full technical reference on this bug check straight from Microsoft, it's documented at Bug Check 0xA: IRQL_NOT_LESS_OR_EQUAL.